Go Conference 2025で発表してきました

Why

今後もいろんなところでCFPを出していくぞ！というメモ書きとしてこれを残します。

※なお、この記事は所属企業団体を代表するものではなく、筆者自身の個人的な意見であることを書いておきます。

What

昨年は落ちたGo Conference 2025はCFPを通したい！と思ってプロポーザルを出したところ採択してもらいました。

goconのパネル

発表内容について

先日開催された Go Conference 2025 で、Goで体感するMultipath TCP ― Go 1.24 時代の MPTCP Listener を理解する というタイトルで登壇してきました。20分の公募 CFP 枠です。

gocon.jp

最後に公開された資料によると単純計算で 27/244 =おおよそ9倍、去年が5倍だったらしいです。

5倍の倍率かー。
プロポーザル、通らないのも仕方ないね。
ちょっと難しい学部の入学試験くらいの倍率？
#gocon

— luccafort@Go Conference 2025 (@luccafort) 2024年6月8日

これは去年のyapcで出てた歴代最高のCFP数と言ってたやつで7倍だったのでそこよりも高いというのは相当ハイレベルなカンファレンスになってたことがわかります。

本当に選ばれるだけでも難しいところを選んでいただけたのは大変光栄です。

CFPを練るにあたっての所感

前述の通り昨年は公募CFP3本(GoCon, YAPC, CNDW)出して唯一落としたのがこのGoConでした。 去年はそのときは 最速のUDPConnを目指して というタイトルで出していました。 これはソケットとしてコンパチビリティを持つけど、裏側に高速パケット処理系を利用した物を使うという話を出していました。このときは残念ながら通過ならずで悲しい気持ちでした。

この経験から、採択されるセッションの多くが Go 言語そのものに近いテーマであることに気付きました。標準ライブラリの解説や有名ライブラリの詳細、PGO など、言語仕様や標準機能に関する話題が多くを占めていました。

いろいろ調べてみるとコロナ以前であれば Go で実装したネットワークコントローラー実装のような、いわゆる「やってみた！」みたいな事例も通っていましたが、傾向が変化していたと自分は思っています。

（※これに関してはいろんな意見があると思いますが、個人的には真っ直ぐに言語系のカンファレンスらしいイベントになってるなと思いました。そういうイベントのカラーだよなと思いますし、公開されてる利用ユースケースはいっぱいあるのでそれで良いんじゃないかなと思ったりしています。）

さて、そこで今回はGo のリリースノートを精査しそこから選ぶことにしました。具体的にはリリースノートから自分が知見を持ち、今話す意義がありそうなテーマを探しました。その結果選んだのが、net パッケージで TCP Listen 時に MPTCP がデフォルト有効化された変更です。 私は昨年、MPTCP の eBPF 拡張を活用した研究を行い、共著で論文やブログも執筆していたため、この分野で質の高い発表ができると判断しました。

www.ipsj.or.jp

blog.bbsakura.net

その結果、このプロポーザルは採択されました。

これは傾向に対しての分析を適切に行なって上でCfPを投稿したというのが良かったのだと思っています。

文章として意識づけたところとして、このようなポイントを意識づけています。

• 明瞭さ：平易な文章で短くまとめる
• インパクト：聴講者が持ち帰れる内容を明示
• 適時性：なぜ今話すのかを事実と共に記述
• 実現性：目安となるタイムテーブルを提示

書いたCFPは以下のとおりです。先程述べたポイントが抑えられてそうなのが理解できるのではないかと思います。

## Goで体感するMultipath TCP ― Go 1.24 時代の MPTCP Listener を理解する

本セッションでは、GoでMPTCPを利用するための方法と、MPTCPの基本的なアーキテクチャを解説し詳しく掘り下げます。
2025年現在、mptcp.ioの測定によるとMPTCPの実世界の利用規模はMPTCP v1で57万以上のIPが確認されています。代表的な例ではAppleやモバイルネットワークなど様々な所で利活用が進んでいます。
Goにおいてはv1.21(2023年)にGo標準のnetパッケージに導入されました。そして、Go v1.24(2025年)でTCPのListen時にデフォルトでMPTCPが有効化されるようになりました。クラウドネイティブ関連のサーバー&インフラソフトウェアで多く利用されるGoで有効化されたことで今後もより活用が進むことが考えられます。このことから、「Goを利用する開発者が今こそ学ぶべき技術である」と応募者である私は確信しています。
セッションを通じて、Go で書いた小さなサンプルとカーネル／ロードバランサ設定の注意点を紹介し、聴講後には自身の環境で MPTCP を動かすための最初の一歩を踏み出せる知識と手順を持ち帰れるようにすることを目指します。

想定している話の流れは以下の通りです  
- 3m: 自己紹介および、セッションの概要説明  
- 7m: MPTCPプロトコルの概説
- 5m: Goでの実装例
- 5m: 運用ノウハウやLinuxの観点からのチューニングポイント

想定してる聴講者は以下の通りです
- Go でネットワーク／バックエンドを開発するエンジニア
- SRE、プラットフォーム担当者
- マルチホーム・モバイル特性を活かしたいアプリ開発者

発表方法について

発表練習は個人で行い、スピーカーノートにはある程度文章でスクリプトを描きました。発表資料・言語は日本語なので緊張はしましたが話が飛んでしまうということはなかったかなと思います。

が、相変わらず話したことをいっぱい詰め込んだら早口になったためマシンガントークと言われてしまいました・・・ﾄﾎﾎ（お聞き苦しくすいませぬ・・・）

takemioさんのマシンガントークいつも面白くて好き🤣 #gocon

— satoken@飲フラSRE (@ken5owata) 2025年9月28日

当日の発表は200人近い人の前で話すことになり流石に緊張しました・・・

終わりに

そうえば、今回は所属企業として初めてスポンサー応募を出して、ブロンズスポンサーを務めました。本当はゴールドスポンサーを目指していたのですが、残念ながら抽選に漏れてしまいました。通る気満々でTシャツとか作って参加してたので、来年はぜひブース出展まで実現できると嬉しいですね笑

また、若手メンバーの学習の一環としてイベントに同行してもらいました。いろんな人の発表に関する感想については、若手の同僚達が記事にまとめてくれているので、ぜひそちらをご覧いただければと思います。（PV数が彼らの励みになります :bow: :bow: )

blog.bbsakura.net

個人的には前述の通り昨年のリベンジができて良かったなと思いました。 運営の皆さん、大変素晴らしいイベントでした。ありがとうございました！！！

今後もイベント登壇を通じてコミュニティに貢献していきたいなと思います！

2024を振り返ってみる

※免責事項：この話は個人の意見や話を主に書いているもので、所属企業や所属団体を代表するものではなく、全て自分の責任です。

Why

• 今年一年は個人的に激動の年だったので振り返りたい。
• 来年の抱負も書き残しておきたい。

時系列で書く方が整理しやすいので、四半期ごとに区切ってみました。読みづらいことや微妙な表現があったりしたらｶﾝﾆﾝしてください🙇

1-3月

1月はJANOG53に参加しました。実は物理ではこれがJANOG初参加です。

以前、学生時代に予定していた福岡回に参加するはずだったのですが、ちょうどコロナ禍が始まり幻の参加となってしまいました。LT参加だけはしていて、SRv6をXDPで実装するぞという話をしました。

今回はそのリベンジ（？）的な感じで以下のスライドをLT発表しました。「NFVのパフォーマンステストするのにk6悪くないぞ」って話です。

次回こそ本発表に挑戦したい！とは思いつつ、本業に直結した話題で議論を深められるテーマを見つけるのが難しいと感じています。これも来年の課題ですね😇 speakerdeck.com

ちなみに、前日にはWakamonog13という、若手エンジニア向けのNOGをやっててそこに参加してきました。「お久しぶりです！はじめまして！あ〜！Twitterでよく見る人ですよね！私フォローしてます」「冷や汗💦」などなどというハートフルなやり取りをさせてもらってました。

そこのNOGでは若者らしくソフトウェアルーターだけどめっちゃパフォーマンス出るようにしたいぜ！みたいな話をしてきました。VPPおすすめなのでぜひ。 speakerdeck.com

その後、今までの人生でも指折りの忙しさを経験することになりました。

具体的には以下のような事柄があったり...

• 東京へ引っ越しとその準備+家探し
• プロポーズと婚約指輪的なアレコレ
• JAISTの社会人大学院の入試
• 本業の開発が色々と佳境に入っていた（+出張があったり）
• その他(後述するジャーナルのreviseとか...)

と、慌ただしく2月3月に突入し自分のバッファは完璧になくなってました。正直前年の終わりの方から秋まではつらぽよ度数がMAXで終わってました。

この時期は労働やプライベート含め諸先輩方には色々とご迷惑をおかけしておりました。。。皆様のおかげで生かされております🙇

3月からは東京での暮らしが始まりました。

東京に引っ越してきてお散歩してて初めて勝鬨橋を渡った時、Creepy Nuts「のびしろ」の「右手にスカイツリー左手に東京タワー」の構図になるには、銀座の街に向かうのではなくて、豊洲とかの住宅街に帰る時なのかー！と何だか感動した記憶があります。

www.youtube.com

4-6月

まぁ何だかんだ無事合格をいただき、ピカピカの一年生(M1)として入学式を迎えることになりました。3年ぶりの学生生活です。

JAISTの方に関してはどこかで詳しく書きたいところですが、ざっくりと言えば、NW系の学生時代進学を考えていた研究室を志望して進めることになりました。コロナ禍で大学院進学を諦めた過去もあり、学び直しの場として大きな一歩となりました。入試では「quick sortの計算量を間違える」「英語でやりたいことを説明しろと言われて詰まる」など散々でしたが、何とか合格。倍率2倍と噂される中での結果に胸を撫で下ろしました。

そのあとはまた冠婚葬祭的なアレコレでプライベートの方はかなり大変厳しかったんですが、いろんなモノをエイやで乗り切る（？）ことで無事婚姻届を出すことになりました。お祝いをくださった皆様大変ありがとうございました🙇まだ送ってないぜ！という人はこちらから送れます:)

www.amazon.co.jp

労働の方に関してまずは前年からリクエストを投げていたLinuxにethtoolのRSS機能に対してGTPをSupportするパッチを入れてもらったというのがありました。初めて自力でLinuxにパッチを入れてもらったので大変興奮しました:) www.spinics.net

他だと昨年やってた成果として、共著で書いてたジャーナルが通りました。 www.ipsj.or.jp

このジャーナルでやってて得たナレッジがここのブログの元になっています。 blog.bbsakura.net

他にも初めて特許の執筆をしたりとか、ネスペ受験して合格したりとか、いろんな開発をしたりしてました。

あとは同僚の方が書いていましたが、「自作OSで学ぶマイクロカーネルの設計と実装」を利用した勉強会を主催していました。同僚氏と技術的な話の学びの時間欲しいよねーということになり、じゃあこういうのやるかと輪読会を自分が提案してはじめました。

結構ガチンコでやれたのがよかったなと思ってます。一緒にやってくれた先輩同僚には感謝しております。同僚がまとめてくれた記録を見ると、4月から8月まで使ってカーネル編を読んでいたらしい。頑張ってて自分偉い。次回はCPU編らしい。頑張れ自分。

blog.bbsakura.net

7-9月

JPNIC News & Views Column「もう一つのインターネット：モバイルローミングの世界」っていう話を書かせてもらいました。もう一つのインターネットって何やねんというとモバイルローミングの話です。

これは事業者間で閉域接続された空間でBGPでPeerされていて、インターネットには出ないし、インターネットの一部でもないけど自立分散のシステムで構築されてるんやで。モバイルネットワークはインターネットのような感じの一面を持つのやで、これってすごいやん！これみたいに社会に貢献していこうな！というポジショントーク丸出しの話をしたモノでした。

文字数制限もあり、ぎゅっと詰め込んだ文章になりました。今見るとちょっと恥ずかしい。 www.nic.ad.jp

また、お誘いされてeBPF Japan Meetup #1で講演をしました。 XDPという高速パケット処理技術とは何か？という話とか、弊社で取り扱ってるXDP製のPGW-Uの話とかをしてきました。

speakerdeck.com

10-12月

YAPC::Hackdate2024で登壇してきました。eBPF LoaderをPerlで書いてみた！という話をしました。Perlの無限の可能性を感じてもらえる資料になっております＞＜

speakerdeck.com

細かい話や聴講の感想はこちらに載っています。 ちなみにADR関連の話はここでかなり良いと思ったのでチームで提案して開始しました。現在は横展開して全社的にそのフォーマットを広げたのでサイクルとして使われていくことを目指したいなと思い啓蒙しています。onkさんの資料はマジで読む価値があって良い。

takeio.hatenablog.com

作ったプロダクトは eCHOで話題にしてもらいました。パスを見ると ebpf-in-perlって書いてる！ isovalent-9197153.hs-sites.com

さらに、Cloud Native Days WINTER 2024ではeBPF Verifierの仕組みを解説しました。立ち見が出るほどの満席で話すのは初めてで、とても緊張しました。

speakerdeck.com

この発表の経緯としては、YAPCでの発表から数日後 inductorさんからこういうリプが来て、面白そうだしやってみるか〜となったモノでした。

全ての元凶はこの人です。良い機会をくださってありがとうございます🙇（注意: もちろん出来レースなどではなくガチンコでCFPは書いております）

eBPFがなぜ安全なのかみたいな話を @udzura または @takemioIO あたりに https://t.co/BgdcdVeO03 で話して欲しい（）

— inductor / Kohei Ota (@_inductor_) 2024年10月9日

今回もトラコンの予選問題を作りました。今回は簡単な問題だったのでいっぱい解かれてて良い気持ち。

blog.icttoracon.net

第一回のeBPF Japan Meetupで登壇してきたその後に運営側に回らないか？とお誘いを受けて、第二回のeBPF Meetup Japanの主催をやることになりました。

今回は自分は前回話したというのもあり、同僚達にそういう機会やチャンスが来るようにしたいなと登壇のタイミングや調整支援などの後方支援に徹していました。

ebpf.connpass.com

あとは年末には恒例のアドカレでこういうブログを書いたり、、、 blog.bbsakura.net

社内で使いたいなーと思ってた機能があったのでVyOSにパッチを出したりしました。

github.com

全体を通した雑な感想

• なんかいろんな初めてをやってて、只今成長中という感じだ...
  • 今年の前半に入試、引っ越し、結婚とか全部詰め込むのは大変すぎる
  • 登壇、OSS、論文、ブログ執筆、特許など一通りやってて今年頑張ってた気がする
• 学生は辛い！社会人に入ってから100分テストを受けさせられたのはびっくりしちゃったぜ。手書きスライド18枚の刑とか本当に辛い。
  • 自腹で学費を払うのもつらい。その分頑張っていきたい。
• eBPF関連の発表をこいつ一年で三回もやってるぞ。。。病気か？
• (悲報)まだ新婚旅行行ってない

抱負

• シニアらしい仕事の振る舞いを身に着けたい

今年で社会人四年目のエンジニアなわけですが、そろそろ若手っぽい立場じゃなくなりつつというのを感じています。 今年の春先に（まだ社会人三年目）に別チームに居るとある先輩エンジニアに「シニアになりつつある君の立場でJANOGに参加してお金になるの？意味があるの？（意訳）」に言われて大変ショックを受けた記憶があります。

自分としては「じゃああなたは僕と同じ様な若手のときに投資対象として参加しなかったんですか？」「自分は当該イベントで発表される情報が生かせる領域で働いてて、そこで登壇も質問も当然してて、イベントで得たナレッジをチーム内に話しててもそれは意味がないと？」って疑問が喉まで出かけましたが......

まぁでも確かにそうだよな、もう若手じゃなくなりつつあるんだなと思ったのも事実で、打席に立った成果を使って技術的にも開発をリードしていきたいと思っています。 もちろん自分のできることは少しづつではありますが増えてると感じてはいます。その出来ることを社会実装に向けてそのプロダクトでお金を稼いで、人を幸せにするようにしたい所存です。

• 登壇をするときに伝わりやすいようなスタイルのスライド構成をしたい

来年も登壇したいな！と思ってるのですが、一方で詰め込んでしまう傾向があるので必要なエッセンスだけを伝えれるように整えて話す練習が必要だなと思っています。どこかの登壇時にオタクが語ってる回と言われてしまってその通りだけど、自重した方がええなとなってます。

• ドロップアウトせずに学生をやり切って論文を一本書くぞ！

やるやる詐欺をしてたり、やろうと思ったことを放置しててまずいのでなんとかしたいぽよ...

終わりに

振り返ると「のびしろ」しかないなという感じで、まだまだ頑張っていきたい気持ちになってます。ただ普段の開発を進めていくという行為やや外部イベントへのコミットという行為は周りの理解あってのものです。妻をはじめとしたや家族や上司・同僚にまずは感謝をしたい気持ちです。ありがとうございます🙇

自分はある意味2年分遅れてNWの世界に戻ってきて開発をしているような気持ちがあります。その分を取り戻すぐらいごりっとコミットして、課題に対していい感じのぶつかり方とかしていきたい。伸び代しかないわ！！！

VyOSにパッチを出す方法

Why

こういうIssueがあり、これに最近取り組んでいる。とりあえず一個PRが取り込まれたので、そのやり方はまぁ正しいっぽいということでここではVyOSの開発の行い方とか、そこで得たナレッジをメモしておく。 vyos.dev

このページに関してはサイレントで気まぐれに更新するかも。

github.com

雑多な（？）テクニック

• パッチの出し方はこれを見ると良い⚡ Submitting a patch
• レビューの返事が帰ってこないときはphabricatorのIssue経由で今こんな感じ！レビューの続き頼む！と騒ぐと進むことが多い
• CIのbuildでlintされている。ruffのコマンドはそこでコピペすると便利
• 基本的に全体的なドキュメントはすごくすごく古いのでフォーラムと自分のコードのチェックが頼り
  • 実際のスモークテストの流れはgithub actionsに書いてるのがわかりやすいので自分で読もう。
  • github.com

ローカルテストまでのたどり着き方

このgistに書いたので詳しくはこれを見るのがおすすめ。展開して貼っておく。

gist.github.com

ただこれでもイメージ毎回ビルドしててすごく遅いので、高速にやる方法を知りたいんだけどどうしたら良いのかいまいちわからん。qemuで動いてるやつに対してsshとか出来ないんすかね...？ CIで動くスモークテスト相当の結果がわかるのに15分ぐらいは最低かかる。なおフィルタせずにやると1時間半位かかってつらい（そしてパッチを入れてもらうためのCIでは普通という...)

Perl開発環境のメモ

hackmdに保存してたので供養ということで覚書メモ。

ライブラリのインストール

cpmがいいらしい https://metacpan.org/dist/App-cpm/view/script/cpm https://zenn.dev/gatapon/articles/7df9511deda6bb

$ curl -fsSL --compressed https://git.io/cpm | perl - install -g App::cpm
$ plenv rehash

(まとめるとパッケージ管理はCarton/Carmelで、モジュールインストールはcpm)

lint とかその辺

cpm install -g Perl::Tidy
cpm install -g Perl::Critic
cpm install -g App::perlimports

precommitはこの辺 https://github.com/henryykt/pre-commit-perl

CPANにuploadするとき

https://metacpan.org/pod/Minilla https://perldoc.jp/docs/modules/Minilla-v0.6.4/lib/Minilla.pod

cpm install -g Minilla

便利リンク

https://rokuokun.hatenablog.com/entry/2024/08/23/220216 https://zenn.dev/anatofuz/articles/2742225639f9f8d7bb98

YAPC::Hakodate 2024で発表してきました

Why

今後もいろんなところでCFPを出していくぞ！というメモ書きとしてこれを残します。

これは懇親会ちらし寿司のご飯の画像

What

YAPC::Hiroshimaを見てて、楽しそうだな〜ぜひ次は参加したい！ つぎはYAPC::Hakodate 2024か！どうせ参加するなら発表したいなーと思ってプロポーザルを出したところ、採択していただけたのでスピーカーとして参加しました。

発表内容について

先日開催された YAPC::Hakodate 2024 で、Perlで始めるeBPF: 自作Loaderの作り方 というタイトルで登壇してきました。40分の公募 CFP 枠です。

倍率としては7倍程度、40分のCFPだけに絞るならば8倍程度の高い倍率で、どうやらYAPCの過去最高のCFP倍率だったそうです。選ばれるだけでも難しいところを選んでいただけたのは大変光栄です。

cf. YAPC::Hakodate 2024のタイムテーブルを公開しました - YAPC::Japan 運営ブログ

speakerdeck.com

私、YAPCは実は初参加でした。YAPC自体は学生時代に旅費支援が通っており存じ上げてたのですが、（幻のKyoto回ですね）私コロナ時期に学生をやっていたので行けなかったという悲しい思い出があります。ところでU25若者支援のレギュレーション的にギリギリそれに合致しないというのがあり、たいへん悲しい気持ちでした😇（発表当日の10/5が26歳の誕生日でぎりぎり超えてしまった・・・）

なにはともあれYAPCに初参加・YAPCで初スピーカーという感じでドキドキでした。いやまぁ流石にまた学生をやってるとは思いませんでしたが・・・

CFPを練るにあたっての所感

YAPCはPerlのカンファレンスですが、近年の性質上、Perlの話をしないでCFPに挑んでくる人が多いところに勝機があるかな〜と思ってました。特に今回の既存CFPを見ると割とお気持ちっぽいソフトな面の話や技術は技術でもPerlの話ではなく別言語から見た、別の立場から見た〜みたいな切り口の入りがPerlではないのが見られた印象です。

ということで、方向としてカニバったりもしないし、おそらくPerlが好きな人が選んでくるイベントであると信じた結果、今回はPerlを使ったプログラム実装者としての話で純粋に勝負しようと検討していました。

以下はCFPに出そうと思った時に書き出した思考のDumpです。eBPFでなければ、BGPを作るとかを話してもいいかなと考えていました。ProxmoxがPerlで内部で書かれてたりするところや最近VXLAN機能が入ったけどそのFRRを置き換えを狙っていくみたいな、そういうインフラソフトウェアにコントリビュートまで目指してみようかな？などの切り口で考えてみたりしてました。が、結局は旬なものが良いだろう（本当に旬か？）と思いeBPFの話で作り込んでいくこととしました。

- [x] YAPC CfPを出す
    - [x] PerlでeBPFをやる
        - [ ] https://fortee.jp/yapc-hakodate-2024/proposal/2c24d2e4-f488-414f-ae3d-1df24180867b
            - [ ] 出しました
        - [ ] 強み: 
            - [ ] eBPFとか旬なモノはウケがいい
            - [ ] コンテナの世界でもperlで遊べる余地が欲しいとか？
        - [ ] 弱み: 
            - [ ] Perlでわざわざやる理由は？があまり答えれてない。ここは議論のポイントにできそうかも？Perlで基本的に書かれてるサービスというのはたくさんあるよね、そこに組み込む際にはPerlの世界とやりとり可能なローダーの実装が必要なんだ！という話で推していくか
                - [ ] 誰が今Perlやりたいんだか謎だが・・・
            - [ ] BCCとかの移植が良さそう？
                - [ ] 普通にBTFのパーサーを書いて systemcallを実行するまでがまず目指すところかな。。。
                - [ ] BCC依存はやりたくない気持ち。Pure-Perlで戦ってみたい。
        - [ ] コレに近そう
            - [ ] https://udzura.hatenablog.jp/entry/2020/03/27/172104
            - [ ] https://udzura.hatenablog.jp/entry/2019/12/10/193302
            - [ ] https://www.perlfoundation.org/grants.html に出してるのをイメージしてみてもいいかも。
            - [ ] https://udzura.hatenablog.jp/entry/2021/12/02/124654

    - [x] 没案
        - [ ] PerlでBGPをやる
            - [ ] 強み:BGPの実装に色々、既存実装はある。
            - [ ] Proxmoxの既存実装のBGPはFRRらしい。そこを超える意味を出せるかどうか。自作BGPdのPR出してみるか？
        - [ ] PerlでQUICを作る
            - [ ] 強み:おもろいし、色々やりようはある。
                - [ ] https://gist.github.com/unasuke/6b1d7cf68059283f1f149f94a327b4b2

発表当日

発表当日までに実装物を作るのは本当に大変でした。 こちらが参考としての実装です。Sys::Ebpfというライブラリになってます。もしよければStarをしてくれると嬉しいです！！！！実装の励みになります！ github.com

スライドの枚数も80枚を超えており、今回はデモを含んでいたので本当に緊張しました。特に会場のWifiでデモが動いたのは正直奇跡で、というのも、イベント開催後半のWifi環境はちょくちょく死んでいたというのがありました。なので危なかったと胸を撫で下ろしていました。

次回やる時はそういう環境も大丈夫か確認したり録画でのフォールバック手段を持っておこうと思います。

次にこのような発表をする場合は以下のようなことに気をつけようと思います

• ソースコードを載せているので解像度はどれくらいかを聞いておく（今回はかなりガビガビだった・・・）
• デモをやるならマイクを持つのは辛いので、ピンマイクがあるかを聞いておく（今回はあった）
• Wifi環境をあらかじめ聞いておけ、SSHはできるか聞いておこう（なお、一応聞いておきました。ありがとう事務局。）
• デモの録画をしろ

それはそうと当日にこのような話がTwitterで反応されたため嬉しくなって共有しました。コミュニティに参加して、コミュニティにも貢献できたとしたら幸せだなぁと思っております。嬉しいw

後から足したスライドなんですが（発表には使ってる）
Perlコミュニティに貢献をした感じが出て嬉しいという話です
（何卒ベストスピーカー投票もよろしくお願いします...🙇）https://t.co/sYZXVmNOpN#yapcjapan #yapc_c pic.twitter.com/E49JuJZ2TD

— 竹 (@takemioIO) 2024年10月5日

参加してみての感想

多様な発表があってよかったなーと思います。印象に残ってる発表を書き残します。

ADR関連の話

LayerXさんのADRのブースが良かったです。実際のADRのサイクルをどう回してるのか、どういうことを書いてるのかを見せてくれたのが大変勉強になりました。 結構根掘り葉掘り聞かせてもらいましたが、そういえばデザインドキュメントとどう棲み分けてるんだろうか？みたいなところまで色々話してくれたのが良かったです。加えて、今回の発表ではてなの人が話してたこちらが色々と自分の知らない知識を補完してくれたのが良かったです。

fortee.jp

プロファイラ開発者と見る「推測するな、計測せよ」

fortee.jp

整合性テストのためにperfコマンドと比べてるみたいな話がなるほどな〜と思いました。 内部的にはkprobeとかでそういう奴らがいると思うんですが、どうしてるんでしょうね。例えばI ラインキャッシュに乗るか乗らないかで出るのものも違う気がしてて、そういう意味ではオブザーバービリティの内部の作られ方がどのような感じになってるのかに非常に興味が持てたセッションでした。 Pythonとかでは内部に手を加えてTrampoline作ったりしてるし、考えることはやはり多いなーと思いました。

さすがベストスピーカーだけあって、やはり話が面白く色々と発表に関しても学びが多かったです。いつかは取りたいベストスピーカー。。。！

クレジットカードを製造する技術

fortee.jp

こちらの発表を聞いてましたが、ほぼSIMやんって驚きました（どこかで言及されてましたが、SIMに似てるという話をしたのは自分です） 質疑をしてて面白いなーと思った点を挙げます。

• BINコードを使う回すことがあるという話で16桁に今後なりそうという話
• フォーキャスト見積りの難しさ
  • 確かにSIMと違って大量にはけていかないし、四年ほどの賞味期限が発生してしまうというのも難しいのか〜とプロダクト性質の点で面白さがある
• 製造したもののコンパチビリティの問題がある->マクドナルドだけで動かないクレカとかがあったという話。
  • これはフィールドワークして見つかる実機の問題という話は、特定の基地局で動かなくなるSIMの話に似てるなぁと思いました。

他にも面白い話が聞けてよかったです。周りの反応を見ててこの発表みたいなのもウケるなら、そのうちSIMの作り方みたいな話をしても面白そうだなぁと思いました。大変良い発表でした。

立ち話で聞いたあれこれ

いんだくたー氏とちくわ氏とWASMに関して結構雑談してて勉強になりました。WASIに関してGC仕様が生えてきてるとかPosixのようなIfaceを作るのかみたい難しさや、ステークホルダー（ブラウザ、CDN、クラウド）の立場で欲しい機能が異なるので大統一は結構大変だよねとか、JVMみたいになりつつあるとか。そういう感じの話です。

なお、ここで根掘り葉掘り聞いてしまったいんだくたー氏はこちらで発表してたようです。素晴らしい。

fortee.jp

この辺、できるなら研究ネタとして良さそうなので掘ってみたいなぁと思いました。

その他雑記

Develop to Survive - YAPC::Hakodate 2024 Keynote - Speaker Deck

moznion san のキーノートが大変良かったです！

最近自分は仕事上でのコンテキストスイッチが重いというので悩んでいるのですが、それは基礎体力がないのかもなぁと思ったりしました。なのでまずは手を動かしていこうと思います。試行回数を増やせるようにしたい気持ちになりました。。。

今後の話

Sys::Ebpfの話ですが、思いの外割と動く感じになってきたので続けたいなーと思っています。が、一方私の普段の開発はGoやCを書いてるので残りはプライベートでやることになるため、Perl FoundationのGrantに出せないかな〜と有識者に繋いでもらって、TPFの方に相談したりしています。Grant自体は今年度は締め切ってしまったので来年度投稿しようかなとか検討しています。もしよければSys::Ebpfに対してPRやユースケース、フィードバックなどがあったら嬉しいです。Starだけでも嬉しい...🥺

最後ではありますが、イベントを開催した運営に携わった人たちや、資料作成や発表へ理解をしてくれている上司や同僚と会社、レビューをしてくれた同僚たち、一回に最低40分かかる発表練習になんども付き合ってくれてマサカリをくれた妻に感謝しています。

色々やっていきの気持ちになったので今後も対外発表や技術から社会とコミュニティと会社に貢献をして強いエンジニアになるべく頑張っていきます！

10/9 追記: Sys::Ebpf の取り組みがIsovalentのeCHOニュースで取り上げられてて嬉しい。

isovalent-9197153.hs-sites.com

takehaya/Sys-Ebpf "perl-ebpf is a pure-perl library to read, modify and load eBPF programs and attach them to various hooks in the Linux kernel" with presentation in Japanese

関連と依存の違い関するメモ

これはJAISTの試験勉強をしててUMLを書いていた際に何が違うんだこれ？となったことのメモです。

ざっくり

参照関係と依存関係の違い

• 参照関係: 具体的なクラスのインスタンスをフィールドや変数として保持し、そのインスタンスのメソッドやプロパティにアクセスする関係を指します。この場合、クラスAはクラスBを「参照」していると言います。
• 依存関係: クラスAがクラスBの存在に依存しているが、そのインスタンスを直接保持していない場合を含みます。依存関係は、インターフェースの使用や一時的なオブジェクト生成など、より広い範囲の関係を指します。 上が依存、下が参照の例

くわしく

依存関係が描かれるケース

1. Interfaceの利用:

   • 例: クラスAがクラスBのインターフェースを利用する場合、クラスAはクラスBのインターフェースに依存していると見なされます。インターフェースが変更されると、それを利用するクラスも変更を余儀なくされる可能性があるため、依存関係として描かれます。

    public class Client {
        private Service service;
   
        public Client(Service service) {
            this.service = service;
        }
   
        public void doSomething() {
            service.performTask();
        }
    }
   

2. 一時オブジェクトの生成:

   • 例: クラスが他のクラスのオブジェクトを直接生成して利用する場合（new キーワードを使用）、依存関係が生じます。このケースでは、生成されるオブジェクトのクラスが変更されると、生成元のクラスにも影響を及ぼすため、依存関係として描かれます。

    public class OrderProcessor {
        public void processOrder() {
            PaymentService paymentService = new PaymentService();
            paymentService.processPayment();
        }
    }
   

3. メソッドの引数として他のクラスを受け取る場合:

   • 例: クラスがメソッドの引数として他のクラスのインスタンスを受け取る場合も依存関係が描かれます。引数として受け取ったクラスが変更されると、そのメソッドを持つクラスにも影響が出る可能性があるためです。

    public class ReportGenerator {
        public void generateReport(DataFetcher dataFetcher) {
            dataFetcher.fetchData();
            // レポート生成ロジック
        }
    }
   

4. 戻り値として他のクラスを返す場合:

   • 例: メソッドが他のクラスのインスタンスを返す場合も依存関係が生じます。呼び出し元のクラスがその戻り値に依存するためです。

    public class ServiceFactory {
        public Service createService() {
            return new ConcreteService();
        }
    }
   

5. フィールドとして他のクラスを保持する場合:

   • 例: クラスが他のクラスのインスタンスをフィールドとして保持する場合も依存関係が発生します。この場合、フィールドの型やインスタンスのクラスが変更されると、そのクラスにも影響を与えるため、依存関係として描かれます。
   • ただし、これは参照関係でもあります。
     • クラスAがクラスBのインスタンスをフィールドとして保持している場合、クラスAはクラスBを参照していると言います。この参照関係は、クラスAがクラスBの具体的なインスタンスに直接依存し、そのインスタンスのメソッドやプロパティを利用するために使われます。

    public class Controller {
        private Repository repository;
   
        public Controller(Repository repository) {
            this.repository = repository;
        }
    }
   

6. 例外処理:

   • 例: クラスが特定の例外クラスをキャッチまたはスローする場合、そのクラスは例外クラスに依存していると見なされます。例外クラスが変更された場合、依存関係を持つクラスにも影響が出る可能性があります。

    public void loadData() throws DataNotFoundException {
        // 処理
    }
   

まとめ

依存関係が描かれるケースは、インターフェースの利用や一時的なオブジェクトの生成に限られません。以下のようなケースでも依存関係が発生し、それがUML図に描かれます。

• メソッドの引数や戻り値として他のクラスを使用する場合
• 他のクラスをフィールドとして保持する場合
• 特定の例外クラスをキャッチまたはスローする場合

依存関係は、クラスが他のクラスやインターフェース、例外、ライブラリなどに影響されるあらゆる状況で発生し、設計上重要な要素となりえるわけです。

Linuxカーネルへのパッチの出し方メモ

これは三ヶ月放っておいたら出し方忘れてしまって、えらく叱られてしまったのでそのためにメモしなおしたものです。とてもつらかった。。。。困ったらChatGPTを使いましょう。破茶滅茶な英文が幾分マシになります。なんか僕が失敗するたびにこのページは勝手に増えます。

最初に読むべきモノたち

• https://www.kernel.org/doc/html/v6.7/translations/ja_JP/howto.html
• https://www.kernel.org/doc/html/v6.7/process/maintainer-netdev.html#netdev-faq
• ここに書いてるから一度これを読んだ上でこの記事を見よう。せめて一本めは日本語なので絶対に読むべき。

チートシート

カーネルの修正

基本的には頑張ってコードを読む以外はなさそう。あたりを付けて書き換えるとかビルドするとか。 とりあえずbuildの仕方とかは載せておこうじゃないか。 基本的にはfullbuildは初回とか、rebaseしたりした時にいる感じ。

git clone git@github.com:takehaya/linux.git
cd linux
git checkout support_rss_gtp
# ubuntu case
sudo apt install linux-image-6.1.0-1008-oem linux-headers-6.1.0-1008-oem linux-modules-6.1.0-1008-oem
sudo sed -i 's/# deb-src/deb-src/' /etc/apt/sources.list
sudo apt update
sudo apt build-dep -y linux
sudo apt install libncurses-dev
mkdir ../build
make olddefconfig O=../build
cd ../build
make localmodconfig
make menuconfig

# build
# CONFIG_SYSTEM_REVOCATION_KEYS のキー情報を消し飛ばしておく
# ICEのコンフィグを有効にして行おう
# cf. https://qiita.com/MNT_QU/items/4b86e56731320f033c3e#config%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6
make -j64 LOCALVERSION=-rss-custom-01
make modules -j64 LOCALVERSION=-rss-custom-01

# package
make bindeb-pkg -j64 LOCALVERSION=-rss-custom-01

# local install
# sudo make modules_install
# sudo make install
sudo apt install ../*.deb

debugのためにビルドして再度適用するときはこちら

make modules -j64 LOCALVERSION=-rss-custom-01
sudo cp drivers/net/ethernet/intel/ice/ice.ko /lib/modules/6.3.0-rc6-rss-custom-01/kernel/drivers/net/ethernet/intel/ice/ice.ko 

sudo modprobe -r irdma
sudo modprobe -r ice
sudo depmod -a
sudo modprobe ice

強いて言うならばこれが参考になるかもしれないですね（古いけど！） https://knqyf263.hatenablog.com/entry/2019/07/01/152643

パッチの送信方法

送るための前準備

# patchのコードスタイルが合っているかどうかを見る
# これが何も出なくなるまで頑張る。
git diff HEAD^ | scripts/checkpatch.pl

# singoff by と言うのをすることでコードに対して署名をする
git config format.signOff yes

# sendemailをするときの対象者を設定する
# (これは特定のgit管理されてるリポジトリで行う)
# に実態が置かれてる
git config sendemail.to "$(git diff HEAD^ | ./scripts/get_maintainer.pl --separator , --nokeywords --nogit --nogit-fallback --norolestats --nol)"
git config sendemail.cc "$(git diff HEAD^ | ./scripts/get_maintainer.pl --separator , --nokeywords --nogit --nogit-fallback --norolestats --nom)"
# ちなみにさらにメールを明示的に追加するならこんな感じである
# git config sendemail.cc "$(git diff HEAD^ | ./scripts/get_maintainer.pl --separator , --nokeywords --nogit --nogit-fallback --norolestats --nom) mailhol.vincent@wanadoo.fr vladimir.oltean@nxp.com"

# smtpの設定などを.gitconfigに入れておく
# 80文字で折り返すようにしておくといいが、実際には手動でぽちぽちやることになるのでなくてもいい。
~/private/linux$ vim ~/.gitconfig 
[sendemail]
       smtpserver = smtp.gmail.com
       smtpuser = hayatake396@gmail.com
       smtpencryption = tls
       smtpserverport = 587
       smtpPass = aaaaaa
       annotate = yes
[format]
        wrap = 80

実際に送りつける

# 単一のちょっとしたパッチはこれで送りつけて大丈夫
# パッチのバージョンに合わせてv6とかv7,v8...に上げていく必要がある
git send-email --annotate -v6 --subject-prefix='PATCH net-next' HEAD

# 意味が変わるようなパッチであれば二つに分割したりする必要がある。例えばuapiとそれに基づいて作られるdriveの機能とか（ethtool.hとiceドライバに関する機能)とかね
# 以下のコマンドで二つのパッチを同時に出せる
git send-email --annotate -v6 --subject-prefix='PATCH net-next' -2 HEAD

# パッチを同時に二つコマンドを実行すると以下のように出てくる。同時に二つ出すのは明示的にパッチシリーズであると言うことにするためだ。
# ここには見えてないがcommit messageとパッチの画面が出てくるのでそこでeditをしよう。
# ちなみに本当にパッチが二つになってるか知りたい場合は、以下に見える /tmp/hoge/v[0-9]-000~が2個あるかどうかで確認しよう。
~/private/linux$ git send-email --annotate -v7 --subject-prefix='PATCH net-next' -2 HEAD
/tmp/B_FPb86TTd/v7-0001-ethtool-Add-GTP-RSS-hash-options-to-ethtool.h.patch
/tmp/B_FPb86TTd/v7-0002-ice-Implement-RSS-settings-for-GTP-using-ethtool.patch
2 files to edit
(mbox) Adding cc: Takeru Hayasaka <hayatake396@gmail.com> from line 'From: Takeru Hayasaka <hayatake396@gmail.com>'
(body) Adding cc: Takeru Hayasaka <hayatake396@gmail.com> from line 'Signed-off-by: Takeru Hayasaka <hayatake396@gmail.com>'

From: Takeru Hayasaka <hayatake396@gmail.com>
To: Jesse Brandeburg <jesse.brandeburg@intel.com>,
        Tony Nguyen <anthony.l.nguyen@intel.com>,
        "David S. Miller" <davem@davemloft.net>,
        Eric Dumazet <edumazet@google.com>,
        Jakub Kicinski <kuba@kernel.org>,
        Paolo Abeni <pabeni@redhat.com>,
        Jonathan Corbet <corbet@lwn.net>
Cc: intel-wired-lan@lists.osuosl.org,
        netdev@vger.kernel.org,
        linux-doc@vger.kernel.org,
        linux-kernel@vger.kernel.org,
        mailhol.vincent@wanadoo.fr,
        vladimir.oltean@nxp.com,
        laforge@gnumonks.org,
        Takeru Hayasaka <hayatake396@gmail.com>
Subject: [PATCH net-next v7 1/2] ethtool: Add GTP RSS hash options to ethtool.h
Date: Thu,  1 Feb 2024 03:33:09 +0000
Message-Id: <20240201033310.1028154-1-hayatake396@gmail.com>
X-Mailer: git-send-email 2.34.1
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

    The Cc list above has been expanded by additional
    addresses found in the patch commit message. By default
    send-email prompts before sending whenever this occurs.
    This behavior is controlled by the sendemail.confirm
    configuration setting.

    For additional information, run 'git send-email --help'.
    To retain the current behavior, but squelch this message,
    run 'git config --global sendemail.confirm auto'.

Send this email? ([y]es|[n]o|[e]dit|[q]uit|[a]ll): y

# この時、yを押すと一つずつパッチが送られる。aを押すと全部送ってくれる感じである

気をつけた方がいいこと

コミットメッセージは80文字で切る

注意点としては文章の区切りで改行を入れるのではなく、コンテキストが続くものは連続で書くべきである。 例えば以下が正しい例である

commit 739a0aac9d26ce2b51bb5ec2da46c8db91129b58 (HEAD)
Author: Takeru Hayasaka <hayatake396@gmail.com>
Date:   Thu Feb 1 03:11:04 2024 +0000

    ice: Implement RSS settings for GTP using ethtool
    
    Following the addition of new GTP RSS hash options to ethtool.h, this patch
    implements the corresponding RSS settings for GTP packets in the Intel ice
    driver. It enables users to configure RSS for GTP-U and GTP-C traffic over IPv4
    and IPv6, utilizing the newly defined hash options.
    
    The implementation covers the handling of gtpu(4|6), gtpc(4|6), gtpc(4|6)t,
    gtpu(4|6)e, gtpu(4|6)u, and gtpu(4|6)d traffic, providing enhanced load
    distribution for GTP traffic across multiple processing units.
    
    Signed-off-by: Takeru Hayasaka <hayatake396@gmail.com>

これを悪くしてみよう。例えば怒られた例だとなるべく句読点で改行したり、適当なはちゃめチヤなところで切ってるやつである。これは正しくするならば、80行ギリギリになる単語で切る。同じ文章のまとまりで初めて改行を入れるべきである。本来であれば二つの塊で問題ないのに、3つの塊にしてたり、80文字までまだまだ単語が入るのに変な位置で切っていると言うのが問題である。

commit 739a0aac9d26ce2b51bb5ec2da46c8db91129b58 (HEAD)
Author: Takeru Hayasaka <hayatake396@gmail.com>
Date:   Thu Feb 1 03:11:04 2024 +0000

    ice: Implement RSS settings for GTP using ethtool
    
Following the addition of new GTP RSS hash options to ethtool.h,
this patch implements the corresponding RSS settings for
GTP packets in the Intel ice driver. 

It enables users to configure RSS for GTP-U and GTP-C traffic 
over IPv4 and IPv6, utilizing the newly defined hash options.

The implementation covers the handling of gtpu(4|6), gtpc(4|6), 
gtpc(4|6)t, gtpu(4|6)e, gtpu(4|6)u, and gtpu(4|6)d traffic, 
providing enhanced load distribution for GTP traffic across 
multiple processing units.
    
    Signed-off-by: Takeru Hayasaka <hayatake396@gmail.com>

正しく空白行を入れる

引用形式の文を書く

レビューをしてくれた人からメールが来るだろう。 その時には相手の文章に対して返信を書くことになるはず。

> 相手の文章

自分の意見

> 相手の文章

自分の意見

と言った感じで書くことがいい ちなみにだが、gmailとかでメールを返信するときは Content-Type: text/plain; にしなくてはいけないので注意。 この辺が参考になりそうです。 https://www.kernel.org/doc/html/next/process/email-clients.html https://nekomatu.blogspot.com/2014/05/howto-send-patch-to-linux.html

パッチの revisionをするとき

こんな感じでrevisionをするときにv1,v2とかの差分をここに書いてあげると親切らしい。

Signed-off-by: Takeru Hayasaka <hayatake396@gmail.com>
---
v2->v3: Based on Harald-san's review, I added documentation and comments to
ethtool.h and ice.rst.
v3->v4: Based on Marcin-san's review, I added the missing code for GTPC and
GTPC_TEID, and revised the documentation and comments.
v4->v5: Based on Marcin-san's review, I fixed rename and wrong code regarding
GTPC
v5->v6: Based on Marcin-san's review, Undoing the addition of unnecessary
blank lines.Minor fixes.
v6->v7 Based on Jakub-san's review, Split the patch.
 include/uapi/linux/ethtool.h | 48 ++++++++++++++++++++++++++++++++++++
 1 file changed, 48 insertions(+)

CIが落ちたりしたので再度叩き込む時

中身は大きく変わるわけではないが、CIが落ちたりしたので再度叩き込む時に必要だったりする。 RESENDをつけることでレビュワーの混乱を防げる。

git send-email --annotate -v7 --subject-prefix='PATCH net-next RESEND' HEAD^

自分のパッチの送付を確認するとき

https://patchwork.kernel.org/project/netdevbpf/list/?submitter=210976 とかpatchworkを見るのが良い。

https://lore.kernel.org/all/20240201033310.1028154-2-hayatake396@gmail.com/ とかでメーリングリストにタイトルを入れるのも良い。